堪比删库！运维恶意破坏生产数据，服务瘫了 36 个小时
The following article is from 程序员的那些事 Author 程序员的那些事
（给Linux爱好者加星标，提升Linux技能）
原创：程序员的那些事（id：iProgrammer）
从删库到跑路的段子，以前我们听到大多数的类似事故，涉事工程师并非故意，而是误删。比如：《2017 年 GitLab 工程师 rm -rf 命令误删服务器的一个目录》和《2018 年顺丰数据中心高级工程师删库事件》。
当然了，也有故意的。比如：《2018 年 12 月意大利某公司，前员工不满解雇，恶意删库报复》。
2020 年首例堪比删库级别的事故
2 月 23 日 19:00 ，微盟公司的服务出现故障，技术定位后发现服务集群无法响应，生产环境及数据遭到恶意破坏。
25 日上午，微盟官网发布了一则通告，解释来龙去脉。一位核心运维员工，因个人精神、生活等原因对公司生产环境做出了恶意破坏。
目前嫌疑人贺某已被刑事拘留。
如果故意破坏生产数据，那不仅免不了刑罚，而且还将给以后职业生涯带来不小的负面影响。
那些误删库的工程师，最后的「遭遇」也不尽相同。顺丰那位高级工程师，被开除了。GitLab 误删库事件，没有开除工程师，反而是直播公开修复过程。
题外话
如何处理非恶意犯错的员工，我记得在 Quora 上看过一个精彩回答。大概意思是：如果把他开除，那就是相当于花费高额代价，给他人培养了一位经验丰富的员工。
看完本文有收获？请分享给更多人
关注「Linux 爱好者」加星标，提升Linux技能
好文章，我在看❤️